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REMARKS/ARGUMENTS 

Claims 4, 8-15 and 18-26 are pending in the Application. Reconsideration and a 
withdrawal of the outstanding rejections are hereby respectively requested. 

Applicant has reviewed the Examiner's comments in the Office Action dated 
April 10, 2007. Applicant believes that its claims are not taught, suggested or disclosed 
by the cited references. The references, even when combined, fail to teach, suggest or 
disclose the Applicant's presently claimed invention. Applicant has amended the claims, 
as indicated above, and addresses below important features of the invention which 
support the patentability of the Applicant's claimed invention over the cited references. 

Claim 8 has been amended to include the steps of: 

preparing said data information from attributes of said data, said data information 
comprising an update_index file, wherein said cryptographic hash of data 
information comprises a cryptographic hash of said update_index file, and 
wherein comparing said cryptographic hash in order to determine if data 
information should be transmitted to said target includes comparing said 
cryptographic hash of said update_index file. 

Claim 8 now more particularly defines the present invention over the cited art, as 
further discussed below. 

New claims 25 and 26 have been added to more particularly define features of the 
present invention. New claims 25 and 26 are fully supported by the specification (see 
e.g., specification [003 8] -[0048], [0051]-[0052]) and no new matter has been introduced. 

NEW CLAIM 25: 
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New claim 25 has been added to more particularly define the invention by reciting 
that the data information comprises a module name and a hash of a module name, and 
that the cryptographic hash is a hash of the data information (e.g., hash of the data 
information contents the module name and hash of the module name). 
NEW CLAIM 26: 

New claim 26 has been added to further articulate and distinguish the Applicant's 
present invention by reciting that the data comprises one or more modules, and that the 
method involves performing an update with an update manager which includes extracting 
one or more modules and replacing files or byte sequences, wherein said one or more 
modules contain directions for replacement of byte sequences. The cryptographic hash of 
the data information referred to in claim 26 (and claims 25 and 4 from which it depends) 
would therefore be a cryptographic hash of the module name and hash for the module 
(which is contained in the update_index file for which the update_hash corresponds). 

Claims 4, 8-15 and 18-21 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over US Patent 6,151,708 ("Pedrizetti") in view of US 6,493,871 
("McGuire") and in view of US 6,006,034 ("Heath"). This rejection is respectfully but 
strenuously traversed and reconsideration and a withdrawal of the rejection is hereby 
respectfully requested. 

The Examiner relies on Pedrizetti, but acknowledges that this reference fails to 
disclose at least three features of the Applicant's claimed invention, namely, that first and 



10 



Application Serial No. 09/800, 1 73 
Response dated: October 10 5 2 0 07 
Reply to final Office Action of April 10, 2007 



E-2538 



second hashes are cryptographic hashes, that the first cryptographic hash is comprised of 
a unique data identifier, and that the second hash is installed on the target. The Examiner 
applies additional references, namely, McGuire and Heath in an effort to supply the 
missing teachings or disclosure. 

Even combining the further references of Heath and McGuire still would not 
result in the Applicant's invention. 

The Examiner considers Heath to disclose, in Fig. 4D, comparing the 
cryptographic hash to determine whether the download should take place (step 419). 
From a reading of Health, the comparison 419 referred to by the Examiner does not 
accomplish what is disclosed and claimed by the Applicant. Applicant has reviewed the 
Examiner's comments and provides a further explanation and clarification with respect to 
Heath and why the Applicant's present invention is distinguishable^ 

Applicant's invention provides for the target to have already installed on it 
cryptographic hashes. The distribution media, such as for example a server, has an 
update index file. The server also has an update hash which is a hash (e.g., a 
cryptographic hash) of the update_index file. As Applicant reads and understands Heath, 
that reference does not disclose using an update index file and determining a hash from 
that. Rather, Heath is concerned with first ascertaining the file name and version number 
(step 416), determining whether that name and version number are present on the client 
(step 418) and then, in a further step (419), determining whether the client component has 
the same cryptographic digest, and, if not, then a retrieval of a component is carried out. 
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Applicant's invention provides and utilizes a cryptographic hash of the 
update_index. That is, the update_hash is returned in response to a request for data 
information (see Applicant's Fig. 1). This has the benefit of requiring and 
receiving/transmitting very small amounts of information (e.g., 50-150 bytes), which is 
designed to handle low bandwidth conditions. According to the Applicant's invention, 
the update_hash is then compared to the client update_hash. If the hashes are not the 
same, then the update_index 1 1 is obtained. (Fig. 2) A request for update_index is made, 
and the server update_index is retrieved/transmitted. The request for code is then made 
and the requested code received/transmitted from the code server (see Fig. 2). As shown 
in Fig. 3, the code is hashed and compared, and the client update_hash and update_index 
are replaced. 

While the Examiner considers Heath for a disclosure of what is considered to be a 
component download and a cryptographic hash (referring to Fig. 4D of Heath), that does 
not disclose Applicant's invention, as illustrated in Figs. 1 and 2 of the Applicant's 
disclosure. Applicant provides an update_hash and compares the server update_hash 
with the client update_hash, thereafter, if the files require updating, the update_index is 
requested/transferred (see Applicant's Fig. 2). It is after the update manager obtains the 
update_index that the code is requested. Heath does not disclose an update_hash, and 
then an update_index, which may require very minimal bytes of information. Rather, 
Heath appears to be attempting to provide a catalog file and one or more components 
before ever proceeding with a step (419) where a cryptographic digest is evaluated. In 
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other words, it does not appear that Heath utilizes an update_hash, but rather as in Fig. 
4D (step 416), has the actual contents communicated from which to read, and not just the 
hash. Thus Heath requires additional bandwidth for what it teaches as compared with the 
Applicant's present invention. 

Therefore, for these reasons, Applicant's invention provides distinguishable 
features and advantages over the Heath disclosure. Applicant's method is important in 
that low bandwidth applications do not require the components to be checked in the 
manner that Heath proposes (which appears to use larger amounts of information that is 
transferred/received), but rather, only an update_hash, which is done before the 
update_index is requested. Heath appears to request the catalog first, and would not 
teach one of ordinary skill in the art to do what Applicant discloses and claims as its 
invention. 

The Examiner in the current office action, on page 7 (and again throughout the 

office action), refers to Heath as disclosing a cryptographic digest or hash that is stored at 

or installed on the target, citing to Heath at col. 5, lines 64-67. That passage of Heath 

appears to discuss the catalog file: 

Information in the catalog file, which at least includes the updated list of 
components and version numbers on the client, is stored at 317 in cache on 
the client until the subsequent version update. 

(Heath, col. 5, lines 64-67) 

Heath, however, does not disclose the installation of the hash of the Applicant's 

update_hash, but rather what appears as the hash as a component of the catalog or index, 
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which contains further information, and is essentially a larger file than the Applicants 
update_hash. Moreover, the passage of Heath cited refers to a download. 

Applicant's claim 4 recites "data" and "data information" and a "cryptographic 
hash of said data information". The cryptographic hash is a hash of the data information. 
This is not disclosed or suggested by the references, in particular the Heath reference. 
Claim 8 also recites "data information" and a "cryptographic hash of data information". 
This claim also would appear to be distinguishable over the cited references, including, in 
particular Heath, as discussed above. 

Applicant has amended claim 8 in order to more particularly distinguish the 

invention over the cited references, including Heath. Amended claim 8 refers to the steps 

of providing the update_index and updatejiash. Claim 8 now specifies that the server 

update_hash is comprised of a hash of the update_index file. 

including preparing said data information from attributes of said data, said data 
information comprising an update_index file, wherein said cryptographic hash of 
data information comprises a cryptographic hash of said update_index file, and 
wherein comparing said cryptographic hash in order to determine if data 
information should be transmitted to said target includes comparing said 
cryptographic hash of said update_index file. 

For the reasons set forth above, claim 8, as amended, is distinguishable over 
Heath and the other cited references. 

For these reasons, even the combination of the cited references with Heath would 
still not teach, suggest or disclose the Applicant's invention. 
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Neither Pedrizetti nor McGuire discloses the Applicant's claimed invention. If 
Heath is attempted to be combined with these references, the combination still would not 
teach the Applicant's invention for the reasons set forth herein. 

The remaining references, together or with Heath also fail to teach, suggest or 
disclose the present invention for yet additional reasons. McGuire fails to provide the 
teachings of the present invention. Applicant's invention is distinguishable over 
McGuire. The cited passage of McGuire that is referred to and relied on in the office 
action indicates that that McGuire requires that "each version of a file is identified by a 
hash number": 

In accordance with a feature of the embodiment, the version identification 
does not rely on typical file version information such as a version number. 
Instead, each version of a given file is identified by a hash number 
generated by applying to it a hash function, such as the known MD5 
algorithm. The hash values of different versions of a given file provide 
unique identifications to distinguish the respective versions. 

(McGuire, col. 9, lines 9-16) 

Accordingly, McGuire, even when combined with the other references (Pedrizetti 

and Heath), still fails to disclose or suggest the Applicant's claimed invention. The 

update_hash, which according to the Applicant's disclosure is a hash of the update_index, 

is distinguishable from what is disclosed by McGuire. Applicant's update_hash is 

described to be a hash of the update index. The update_index is disclosed by Applicant 

to itself contain a hash as part of the information records. (See Applicant's published 

Specification at [003 8] -0048]). This is not what McGuire appears to disclose. 



15 



Application Serial No. 09/800,173 
Response dated; October 10, 2007 
Reply to final Office Action of April 10, 2007 



E-2538 



For the above reasons, the Applicant's invention is not taught, suggested or 
disclosed by the cited references. Applicant's invention as recited in the claims, including 
in the new claims 25 and 26, should be patentable. 

Reconsideration and a withdrawal of the 103(a) rejection is respectfully 
requested. 

Claims 22 and 23 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over by US Patent 6,151,708 ("Pedrizetti") in view of US 6,493,871 ("McGuire") in view 
of Ayers (U.S. 6,389,592) and in view of US 6,006,034 ("Heath"). This rejection is 
respectfully but strenuously traversed and reconsideration and a withdrawal of the 
rejection is hereby respectfully requested. 

For the same reasons set forth above, Applicant's invention is not obvious in view 
of the cited references. Reconsideration and a withdrawal of the 103(a) rejection is 
respectfully requested 

CONCLUSION 

Applicant's invention is not taught, suggested or disclosed by the cited references 
relied on by the Examiner. Accordingly, Applicant's presently claimed invention should 
be patentable. 

If further matters remain in connection with the case, Applicant respectfully 
requests an interview with the Examiner. 
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If necessary, an appropriate extension of time to respond is respectfully requested. 

The Commissioner is authorized to charge any additional fees which may be 

required to Patent Office Deposit Account No. 05-0208. 

Respectfully submitted, 
JOHN F. A. EARLEY III 
FRANK J. BONINI,JR. 
CHARLES L. RIDDLE 

HARDING, EARLEY, FOLLMER & FRAILEY 
Attorneys for Applicant 

Frank /. BoninyJr. 
Registration N6. 35,452 
P.O. Box 750 

Valley Forge, PA 19482-0750 
Telephone: (610) 935-2300 



Date: 
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